voice over IP telephony, streaming video, or the like (pg. 7, lines 22-25). This definition of real 
time is well understsood in the networking industry, see Newton's Telecom Dictionary, 17 th 
Edition, February 2001, CMP Books, where real time is defined: "A voice telephone conversation 
is conducted in real time. That is, there is no perceived delay in the transmission of the voice 
message or in the response to it." Applicant, therefore, traverses the Examiners reading of "real 
time" in Lorrain with the concept of "validated" as used by the Applicant. Specifically, as stated, 
validated traffic is independent of the type of traffic, i.e. validated traffic can be real time or non- 
real time traffic. 

Neither Kloth, nor Lorrain, individually or in combination, describe validating traffic 
flows, as claimed in Claims 1-16 of the present application. As described with reference to 
Figure 5, validating traffic flows include examining the flow to insure that it conforms to 
expected characteristics such as reordering or reassembling correctly, and conforming to enforced 
protocols, and by insuring that the flow itself is validated by checking flow parameters over 
enough data packets for it to be classified. Also, validating a particular flow is inherently 
different than determining if traffic is real time or non-real time. Determining real time from 
non-real time traffic requires only examining the header of the packet to determine the protocol, 
such as RTP, UDP, or TCP, which indicates the type of traffic in the packet. Validating as 
described above requires knowledge in the network equipment of the characteristics of the 
particular protocols to check to see if the packets conform to those protocols, as well as 
knowledge of the source of the packets such as matching physical input information against 
source address/port information in the header, and even knowledge of attributes of the customer 
associated with the source address. None of the types of validating, as set out by the Applicant, is 
described by Kloth or Lorrain who merely look at header information to determine the type of 
traffic. 

Since neither Kloth nor Lorrain, individually or in combination, show the validating of 
network flows and the treating of those flows according to whether those flows are validated, and 
since these limitations are clearly set forth in Claims 1, 7, and 12 and therefore, dependent Claims 
2-6, 8-11 and 13-16, Applicant respectfully asserts that Claims 1-16 are not obvious over Kloth in 
view of Lorrain, requests that the rejection by the Examiner be withdrawn. 

Applicant believes in view of the foregoing amendments and arguments that the 
application is in condition for allowance and respectfully requests such action by the Examiner. 
If there are any issues, questions, or if the Examiner does not believe the application is in 
condition for allowance, the Examiner is invited to call the undersigned attorney at the number 
below. 
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Respectfully submitted, 



Craig J. Cox 
Reg. No. 39,643 

Date: September 29, 2004 
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